…4770)

A declarative hook `condition` was evaluated against `ctx.input.data` — the
fields the current write happens to carry. `ctx.previous` sat behind it,
unreachable, and the two were never merged, so a condition could only reference
a field the update touched. Anything else aborted the CEL expression with
`No such key`, which the gate swallowed into `false` plus one WARN line.

For a guard-style hook that reads as "let it through"; for an audit-style hook
it reads as "do not record it". `showcase_audit_task_completion`
(`record.done == true`) therefore did NOT run on the most ordinary updates
there are — change the status, change the assignee — and the only trace was ten
warn lines per showcase boot.

The record a condition reads is now built exactly the way a validation
predicate's is (#1871 / #4649): stored ⊕ payload, made total over the object's
DECLARED fields, `null` when a declared key is in neither. `materializeDeclaredFields`
moves out of `validation/rule-validator.ts` into `declared-fields.ts` and is
shared by both paths, because `record.done == true` must not mean two different
things depending on which surface evaluates it.

Declared-only is the load-bearing half: a typo'd or undeclared key stays
unevaluable and is still reported. Materialisation runs only when the persisted
state is in hand — an insert, or an update whose prior row was fetched — so a
predicate bulk update keeps its payload rather than gaining nulls that
contradict N stored rows. `ctx.ql.getObject()` is an in-memory registry read;
no code path fetches a record it did not already load.

Out of scope, deliberately unchanged: what happens when a condition is STILL
unevaluable after merging (warn + treat as false). Its failure direction is
opposite for guard and audit hooks and is tracked separately.

`has(...)` is not a null guard once the record is total — the showcase's
over-budget condition is rewritten with `!= null`, and the hook docs that
prescribed `has(record.x)` are corrected with it.

Evidence: `pnpm dev -- --fresh` on this branch logs 0 `condition evaluation
failed` lines; the same boot with the fix reverted logs exactly the 10 the issue
reported.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018iARDqtrhQgz6fVHDeDkbQ